Date: Sat, 21 Aug 93 04:30:18 PDT 

From: Ham-Digital Mailing List and Newsgroup <ham-digital@ucsd.edu> 
Errors-To: Ham-Digital-Errors@UCSD.Edu 

Reply-To: Ham-Digital@UCSD.Edu 

Precedence: Bulk 

Subject: Ham-Digital Digest V93 #15 

To: Ham-Digital 


Ham-Digital Digest Sat, 21 Aug 93 Volume 93 : Issue 15 


Today's Topics: 
assistance: modem <-> x-mitter/receiver link 
Autopatch (phone patch) 
Digital Hierarchy 
Small TNC 


Send Replies or notes for publication to: <Ham-Digital@UCSD.Edu> 
Send subscription requests to: <Ham-Digital-REQUEST@UCSD.Edu> 
Problems you can't solve otherwise to brian@ucsd.edu. 


Archives of past issues of the Ham-Digital Digest are available 
(by FTP only) from UCSD.Edu in directory "mailarchives/ham-digital". 


We trust that readers are intelligent enough to realize that all text 
herein consists of personal comments and does not represent the official 
policies or positions of any party. Your mileage may vary. So there. 


Date: 21 Aug 1993 08:17:04 GMT 

From: news.cerf.net!nic.cerf£.net!patrick@network.ucsd.edu 
Subject: assistance: modem <-> x-mitter/receiver link 

To: ham-digital@ucsd.edu 


In article <CC3CCu.216@NeoSoft.com> sengle@blkbox.COM (Steven W. Engle) writes: 
>I need to link two computers together via a wireless link. 

>... (all sorts of stuff omitted) 

>Steve Engle 

>sengle@blkbox.com 

> 


It might be worth rethinking your design. A frequently used technique 

for close wireless communciation is via infra-red transmitters and receivers; 
exactly the way your remote control talks to your VCR. A simple circuit 
including a UART for parallel to serial conversion and an IR transmitter/ 
receiver for the wireless link can provide an easy to program two 

way link which works as long as the IR beam reaches both stations. 

It would also seem feasable to use a standard RS-232 port for the 


serial communication by simply adapting an IR link between the two 
computers’ ports. JI recommend consulting historic Radio and Electronics 
magazines for more specific part number and circuit information. 


Hope this helps! 


-patrick@cerf.net 


Date: 20 Aug 93 17:59:15 GMT 
From: news-mail-gateway@ucsd.edu 
Subject: Autopatch (phone patch) 
To: ham-digital@ucsd.edu 


I would like to buy an autopatch (phone patch) in order to set up 
a mobile phone using two handhelds (Icom 24AT). 


Conveying your recommendations and sharing your experience in this 
regard will be very much appreciated. 


Does anyone know of the regulations for using autopatch? 


Many thanks in advance 


Regards, 
Ali Taalebi 
taalebi@ai.mit.edu 


Date: 19 Aug 93 06:42:03 GMT 

From: rtech!amdahl!amdahl!ikluft@decwrl.dec.com 
Subject: Digital Hierarchy 

To: ham-digital@ucsd.edu 


[Followups to rec.radio.amateur.digital.misc] 


ben@nj8j.atl.ga.us (Ben Coleman) writes: 

>Of course, the question will be(consider this a preview of what the 
>discussion will look like in news.groups when this RFD gets cranking ina 
>few months): is there sufficient traffic to justify the new groups? 


Yeah, agreed. When you propose a new newsgroup, you need to xknowx that 
you're putting your proposal out to some very skeptical masses that could, 
and probably will, tear it apart. Of course, I'm not saying that's bad - the 
net would be a big mess (well, bigger mess than it is :-) if it wasn't 


difficult to make a new newsgroup. 


>Obviously, there will be another try at creation of rrad.tcpip. Based 

>on what I've seen recently, rrad.packet will probably be in the running 
>also. But is there really enough RTTY, AMTOR, or PACTOR traffic on here to 
>justify a separate newsgroup for them? In the end, I think they will be 
>left to rrad.misc until enough long-term traffic shows up to justify 
>creating separate groups. 


I also would not be surprised if another try is made at r.r.a.d.tcpip. But 
there was already quite a bit of resistance at moving the r.r.a.packet to 
r.r.a.d.misc. I'11 go with the flow on a r.r.a.d.packet but I would not 
look forward to the mess that will cause with the mail lists again. 


Anyway, it's still a long way off. Ben mentioned this but I'll expand on it. 
r.r.a.d.tcpip failed the last vote so it has to wait 6 months before anyone 
can try again. That will be January 1, 1994 for the earliest possible 
posting of a Request for Discussion (RFD). Assuming that goes well, it will 
be 21-30 days before voting can begin, which would also be 21-30 days. So, 
no matter how enthusiastic anyone is for it, it can't happen before February 
or March of next year. So be patient... let's properly settle into the new 
groups we just got before jumping to make more. 


If anyone's interested, I'd expect that the initial discussion for an RFD will 
happen on the "rec.radio.amateur working group" mail list - a collection of 
the volunteers who post periodic informational articles & FAQs, the moderator 
of rec.radio.info, some ARRL staff, and other regular participants in the 
rec.radio.amateur newsgroups. If you think you'd like to be a part of it 

or just watch, it's always open for you to join. Just send a message to 
rra-wg-request@amdahl.com and ask to join the list. Don't forget to include 
your callsign so you can be properly introduced to the group. 


Ian Kluft KD6EUI PP-ASEL Amdahl Corporation, Open Systems Development 
ikluft@uts.amdahl.com Santa Clara, CA 
[disclaimer: any opinions expressed are mine only... not those of my employer] 


Date: 20 Aug 93 18:01:30 GMT 
From: news-mail-gateway@ucsd.edu 
Subject: Small TNC 

To: ham-digital@ucsd.edu 


Trond (trond@phys.ucalgary.ca) writes: 
>I would like to go portable on packet and now I wonder what is the 


>(physically) 
>smallest TNC available? I will only need to be active on vhf/uhf. 


>Power consumption is also an important factor. 
>It seems to me that a tne could be made extremely small... 


>I have not been looking in mags/brochures for years, 
>so I have lost touch with 
>what the state of the art is. :-) 


>73 
>Trond 


You probably have heard about the software based TNC's such as BayPac and 
"Poor Man's Modem". 


Besides those, there is a small self-contained TNC called AR210 
(export version of the TNC-210 made by Tasco, Japan). 


It it the improved version of the TNC-u II or 
HK21 (which used to be sold in the US by Heath Kit). 


Some specs are: 


- ac/dc plug on the back (10-13 V, 100 mA), 

- can run on a rechargeable battery ($20 extra!) 

- supports the KISS mode, 

- 1200 baud, 

- cabel ready for Handhelds, 

- 60mm(W) x 100mm(L) x 20mm(H), 

- 9 pin serial port on the back (HK21 was 25 pin!), 

- front panel accomodates the power switch, LED's and R/T plugs. 


Note: As opposed to the HK21, there is no removeable chips inside. 
The new surface-mount technology is used! 


Henry Radio in California (800-877-7979) sells it for 
$180 (rechargeable battery and adaptor not included). 
It seems expensive to me, however I like its compactness and neat packaging. 


If you decide to buy one, make sure to ask them to include the manual. 
They forgot to send me the manual. 


--73's de N1HPP 


ss _ M. Ali Taalebinezhaad, 
/ ) // The Canadian Institute 
/- -/ // o for Robotics and Intelligent Systems 
/ /_</_<_ Phone: (418) 656-2131 (Ext. 8026) 


Fax: (418) 656-3594 

Email: taalebi@gel.ulaval.ca 

Addr.: Robotics & Vision Laboratory 
Pouliot Bld., Room 00114 
Elec. Eng. Dept., Laval Un. 
Quebec, PQ, GiK-7P4, Canada 


Date: Thu, 19 Aug 1993 17:59:14 GMT 

From: nntp.ucsb.edu!mustang.mst6.lanl.gov!nntp-server.caltech.edu! 
news.claremont.edu!ucivax!news.service.uci.edu!usc!sdd.hp.com! portal! 
lhaven.UUmh.Ab.Ca!combdyn! Llawrence@network.ucsd.edu 

To: ham-digital@ucsd.edu 


References <24s89t$53v@vixen.cso.uiuc.edu>, <24th89$9e0@usenet.INS.CWRU.Edu>, 
<willmore.745692273@metropolis.gis.iastate.edu>ice.uc 
Subject : Re: TCP/IP and unix machines 


In article <willmore.745692273@metropolis.gis.iastate.edu> willmore@iastate.edu 
(David Willmore) writes: 

>From my reading I would say that encryption is not allowed, but crypto used 
>for authentication is ok. As long as you're only proving who you are and not 
>telling anyone anything (sending a message) I don't think that there would 
>be any conflict. Think about access to a autopatch. You have to have a code 
>to access it, what's the difference? 

> 

Yeah, but the code can't stay a secret to access the autopatch....anybody with 
a DTMF decoder can figure out what the autopatch (or linking) codes are. They 
can also figure out what number you are dialing. 


| WORK: lawrence@combdyn.com | (403)529-2162 | (403)529-2516 | CallSign 
| HOME: dreamer@lhaven.uumh.ab.ca | (403)526-6019 | (403)529-5102 | VE6LKC 


disclamer = (working _for && !representing) + (Combustion Dynamics Ltd.); 


Date: Thu, 19 Aug 1993 17:51:47 GMT 
From: gecko! lanzo@uunet.uu.net 
To: ham-digital@ucsd.edu 


References <24pqjc$nk3@vixen.cso.uiuc.edu>, <24rsib$icc@usenet.INS.CWRU.Edu>, 
<24s89t$53v@vixen.cso.uiuc.edu>com 


Reply-To : lanzo@tekelec.com 
Subject : Re: TCP/IP and unix machines 


In a prior article ...green spleen... <dobrowol@ux1.cso.uiuc.edu> wrote: 
[ prior discussion omitted ... ] 
> What I meant to ask was how passwords are sent over packet. 
> Wouldn't others 
> be able to "see" a user's password if they were just sent over the 
> air ‘as is'? 


Absolutely. If you are concerned about privacy, then amateur 
packet radio is the wrong place for you. All of the data 
sent between stations is “in the clear", so you certainly 
wouldn't want to use it as the medium for transferring any 
"delicate" information. 


There's not much we can do about this either under present 
regulations, since using codes / cyphers or other things 
whose purpose is to "obscure meaning" is forbidden. 


Locally, most of our TCP/IP packet stations just use 
callsigns as the "login" id's, and the person's first 
name as the "password" (or don't have one at all). 

In fact, most of the stations here will accept any 
callsign for the login-id -- the default is to let an 
unrecognized user on without even bothering with a 
password. 


Note though that this doesn't necessarily apply to whatever 

Unix SW you are using. The packet stations around here 

which run TCP/IP usually are on Amigas or IBM-PCs running 0S/2 -- 
and any notion of "user accounts" or "login ids" is something 
maintained by the packet software, not the underlying OS. 


I don't know about any Unix packet radio SW per se, but it 
may well be the same -- that the packet radio "accounts" 
exist purely within the packet radio SW (running under one 
real Unix login probably) and aren't otherwise related 

to Unix accounts. On the other hand 


Anyone wanna provide a synopsis of packet radio software 
available for Unix systems and how it works? 


End of Ham-Digital Digest V93 #15 
KKKKKKKKKKKKKKKKKKKKKKKKEKR KAKA 


